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BACKGROUND OF. THE INVENTION 
The present invention relates to a method for 
providing software technical support from « remote location 
via, for example, the Internet. More specifically, the 
present invention provides a method by which software upgrades 
and fixes for software bugs may be incorporated into a 
customer's software from the remote location. 

Once a software producing company has sold a 
software product to its customer, it is extremely important to 
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keep track of these customers and to update the software 
periodically. No software program is ever bug free; in fact, 
the software industry is quite accustomed to re-relaasing 
newer versions of software programs on a periodic basis in 
order to correct errors in the software. Obese later releases 
nay add new features to the software, nay correct minor 
problems, or often correct critical errors in the software. 
Because the performance of a software program is important for 
customers, it is in a software company's best interest to 
release these later versions of software to its customers and 
to insure that the newer software versions are received and 
installed correctly. 

However, numerous obstacles are present that thwart 
even the best efforts of a conscientious software company to 
periodically update its software products with newer versions 
for all of its customers. One problem is that few customers 
who buy a software program go through the formalities off 
registering the program and sending the registration bach to 
the software company. A registration form allows a software 
company to keep track of purchasers of its software, their 
addresses, contact persons, the version purchased, etc. 
However, few such software registration forms are received by 
software vendors. This makes it extremely difficult for a 
software company to determine to whom regular updates should 
be sent. For those software companies that update software 
regularly (such as quarterly) or may need to correct critical 
software bugs, this lack of software registration presents a 
real problem. And eves if a registration form has been 
received, it is often difficult to figure out exactly to whom 
the new software version should be directed. Individuals 
change roles within an organization, organizations merge • 
engineers leave, etc., all making it extremely difficult 'to 
figure out to whom within an organization a new software 
version should be sent, it is also important that new 
versions of software be sent to a responsible person within 
the organization to ensure that all computers running the 
software are updated with the new version, and that the 
installation is done correctly. However, even with such 
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competent individuals, errors in installation* 

Another problem with releasing new versions of 
software to customers is the problem of distribution. In 
order to release a new version of the software, the vendor 
must purchase floppy or compact disks to hold the software, 
copy the software onto the disks, label the disks, determine 
who the appropriate customers and contacts are, and label and 
mail these disks to the correct Individual. But as mentioned 
above, even if these disks containing the latest software 
version arrive at the correct location, there is no guarantee 
that the software will be installed correctly. Any problems 
encountered with the software, either due to bugs or incorrect 
installation will undoubtedly be blamed upon the software 
company that has sold the software program. 

Xt is clearly in the best interests of a software 
company to ensure that updated versions of its software are 
timely received by the correct individuals within one of its 
customers, and correctly installed. 

Another problem encountered by software companies is 
the identification and correction of software bugs encountered 
by customers in the course of using their software. 
Typically, a customer receiving an error massage while using 
software will call the software company and relate the 
circumstances surrounding the problem. Such a user may be 
able to relate generally what he was doing at the time, 
describe the problem that occurred, and report any error IP 
number that was produced. However, it is rare that specific 
details Involving computer configuration, other programs 
running, and the status of internal variables are reported. 
Essentially, the problem is that the customer is in a location 
isolated from the software company when the problem occurs and 
has no means of transferring a "snapshot* of hie system at the 
time the error occurs. 

Of course, if the customer discontinues use of the 
software, ignores the problem, or otherwise chooses not to 
contact the software company with news of the error, the 
software company is put at a disadvantage. In these 
situations, because the vendor does not hear about the 
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occurrence of the problem, it is not given the opportunity to 
correct it. Because errors in software can be extremely 
complex and subtle, it is very important for a software 
company to know exactly the circumstances under Which tbe 
problem occurred in order to be able to reproduce the problem 
and to solve it. For customers using the software at a remote 
location on a remote computer, it is unlDcely and extremely 
difficult that a customer will be able to transfer all of the 
information concerning such a problem back to the software 
company. 

it is therefore desirable that a technique be 
provided by which a software vendor can track customers, 
upgrade customer software with newer versions, and correct 
software bugs from remote locations. 

SUMMARY OP TOe INVENTION 
According to the present invention, techniques are 
provided fay which a software vendor may provide software 
technical support to its cub t amors from a remote location via 
the Internet. When the end user begins operating the vendor's 
software, dialog boxes give the user the opportunity to 
register the software with the vendor. If the user decides to 
register the software, a connection between the user's 
platform and the vendor is established via the Internet to 
effect registration. Moreover, each time thereafter that the 
user begins operating the software, an Internet connection to 
the vendor is established for the purpose of determining 
whether a software upgrade is necessary. Version data for 
each of the software's modules as well as any critical bug 
data Xnown by the vendor are downloaded to the user's platform 
for comparison to the user's current version or the software. 
Where the downloaded version data agree with the user's 
module versions, and where thers are no known bugs, the user's 
software remains unchanged. However, if the comparison 
reveals that one or more of the user's software modules are 
outdated or Infected with a critical bug, dialog boxes are 
presented to the user for each such module requesting whether 
an upgrade is desired. A list is maintained of the modules 
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for which an upgrade is requested. When all of the modules 
have been checked in this manner, the latest version of the 
modules in the upgrade list are downloaded from the vendor and 
wit ten over the corresponding outdated modules on the user's 
platform. 

According to another embodiment of the invention, a 
method is provided by which a vendor may effectively 
troubleshoot errors in the operation of its software from a 
remote location via the Internet. When a user encounters an 
error in Che operation of the vendor's software, operation of 
the software Is suspended end an Internet connection to the 
vendor is established by which the error is reported and known 
critical bug data are downloaded to the user's platform. The 
critical bug data ore compared to the state of the user's 
software to determine whether the error corresponds to any 
known bugs previously documented by the vendor. Where the 
error corresponds to a known bug, the user is given the 
option, e.g., via a dialog box, to download a software fix 
from, the vendor. This may be, for example, a replacement 
module to overwrite the module with the bug. Where, however, 
the error does not correspond to any known bug, software on 
the vendor's platform determines what information must be 
uploaded from the user's platform, subject to the user's 
authorisation, in order to recreate on the vendor's platform 
the conditions under which the error occurred; this for the 
purpose of troubleshooting the error loeally, i,e., on the 
vendor's platform. If the user does not authorize the upload, 
the vendor supplies information to the user regarding the 
nature of the error (to the extent possible) and an 
appropriate contact person with whom the user may attempt to 
solve the problem. 

Thus, the present invention provides a method for 
upgrading first software. According to the invention, in 
response to operation of tne first software on a first 
platform, a connection is established between the first 
platform and a remote platform. Where first version data 
associated with the first software are different from second 
version data from the remote platform, a portion of the first 
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software is overwritten with first updated code from the 
remote platform. 

The present invention also provides a method for 
troubleshooting first software. According to the invention, 
in response to an error in operation of the first software on 
a first platform, a connection is established between the 
first platform and a remote platform. Where the error 
corresponds to known error data from the remote platform, a 
portion of the first software is overwritten with updated 
code. 

a further understanding of the nature and advantages 
of the present invention may be realized by reference to the 
remaining portions of the specification and the drawings. 



8RXSF DESCRIPTION OF THB DRAWINGS 
Fig. X is a diagram of a network environment in 

which specific embodiments of the present Invention may be 

implemented/ 

Fig. 2 is a flowchart Illustrating remote 

registration of software according to a specific embodiment of 

the invention; 

Fig. 3 is a flowchart Illustrating remote upgrading 

of software according to a specific embodiment of the 

invention; 

Figs- 4a and 4b are flowcharts illustrating remote 
troubleshooting of software according to specific embodiments 
of the invention; 

Fig. 5 is a flowchart illustrating access of help 
files according to a specific embodiment of the invention; 

Fig. 6 illustrates an example of a computer system 
that may be used to execute the software of an embodiment of 
the invention; and 

Fig. 7 shows a system block diagram the computer 
system of Fig. 6, 
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DESCRIPTION OF SPECIFIC EMBODIMENTS 
Pig* 1 ia a simplified reprep natation of a network 
environment in which specific embodiments of the present 
invention may be imp 1 ©men tod. customer platform 100 is a 
workstation or personal computer (PC) on which aof tware from a 
particular vendor is installed. An example of the type of 
software installed on customer platform 100 which may be 
employed with the present invention is described in commonly 
assigned, copending U.S. Patent Application Serial No. 

08/ for METHOD AND APPARATUS FOR AUTOMATED CIRCUIT 

DESIGN, filed simultaneously herewith, the entire 
specification of which is incorporated herein by reference. 
Software used to design circuits such as, for example, 
programmable logic devices, is extremely complex and, as such, 
is the type of software which could especially benefit from 
the features of the present invention. That is, such software 
typically requires its vendor to maintain a large technical 
support capability to ensure customer satisfaction. It will 
be understood i however, that the techniques described herein 
may be applied to a vide variety of software without departing 
from the scope of the invention. 

Customer platform 100 res idea on a local area 
network (IAN) 102 with a file server 104 which is, in turn, 
connected to the Internet 106 via a router 108. Vendor 
platform 110 is a file server which is remote from LAN 102 and 
is connected to internet 106 via router 112. It will be 
understood that the network environment illustrated in Pig. 1 
is one example of an environment in which the present 
invention may be practiced, and that a wide variety of network 
configurations may be employed without departing from the 
scope of the invention. 

According to the invention, a customer may effect 
registration of software with the vendor via the Internet. A 
specific embodiment of this aspect of the invention will now 
be described with reference to flowchart 200 of Pig. 2. When 
the customer or end user begins operating the software on her 
platform (step 202), the software determines whether access to 
the internet is available (step 204) . If not, & dialog box is 
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presented instructing the user to contact the software vendor 
for registering her copy of the software (step 206) . If , on 
the other hand. Internet access is available, the software 
presents a dialog box prompting the user to authorize 
registration of tne software (step 208) . if the user does not 
authorize moving forward with the registration process (step 
210). che software registration routine ends end the user may 
proceed with normal operation of the software. However, if 
the user does give authorization, an Internet connection is 
established between the user's platform and the vendor (step 
212) by which registration of the software is effected (step 
214). once the software is registered, normal operation of 
the software en the user's platform may proceed. 

Severel advantages result from software registration 
achieved in the above-described manner. Because of the 
automated nature of the registration process described herein, 
the registration of a software product employing this process 
xs much more likaly to occur than if the onus for effecting 
registration Is placed entirely on the customer as in the 
case, for example, of registration by mail. And. when vendors 
know who has purchased their software, they are in a better 
position to provide the technical support necessary to enable 
their customers to use their products to their greatest 
advantage, in addition, with accurate customer data, vendors 
are better able to develop product design strategies which are 
responsive to the needs of their customer base. 

Fig. 3 is a flowchart 300 illustrating a method by 
which a customer's software nay be upgraded according to a 
specific embodiment of the invention. When tbe customer or 
end user begins operating the software on her platform (step 
302), the software determines whether access to the Internet 
is available (step 304). if not. and the user's software is 
older than some predetermined aging period, a dialog box is 
presented instructing the user to contact the software vendor 
for determining whether she has the latest v-r.xon of tbe 
software (step 306). if. Cor ^ 8o£twar . ia voatM 

quarterly, the dialog box is presented if the version of the 
software on the user's platform is more than three months old 



(25) 



ft§8¥ 10-222374 



If, on the other hand, Internet access is available, 
the software presents a dialog box prompting the user to 
authorize connecting to the vendor for this determination 
(step 308) . In either case, the user is also given the option 
of indicating that she does not wish to be asked again 
regarding updating cue software. Zf the user does not 
authorize the connection (step 310) , the software upgrade 
routine ends and the user may proceed with normal operation o£ 
the software. However, if the user does give authorization , 
an Internet connection is established between the user's 
platform and the vendor (step 312) by which the upgrade 
process may proceed. 

Data are downloaded from the vendor to the user's 
platform regarding the most current version of the software 
and any critical software bugs Known to the vendor (step 314) . 

These data are used to determine whether the user's software 
is appropriately updated and whether any of the modules of the 
software are affected by the known bugs. Bach individual 
module of the user's software i» selected and compared to the 
version and critical bug data (step 316). where the version 
number of the selected module and the version data agree (step 
318) and where modules remain which have not been checked 
(step 319), another module is selected for comparison. If at 
step 318 the selected module is determined not to be the 
latest version, it is then determined whether the critical bug 
data identify the selected module (step 320) . i£ not, a 
dialog box is generated asking the user whether the module 
should be upgraded (step 322) . if the user indicates that the 
module should be upgraded, it is added to an upgrade list 
(step 324). if at step 320 the. selected module is identified 
as having a critical bug, a dialog box describing the nature 
of the bug is generated asking the user whether the module 
should be upgraded (step 326). Again, if the user authorizes 
the upgrade, the module ia added to the upgrade list. 

According to a specific embodiment of the invention 
the critical bug data downloaded from the vendor's platform 
may be employed to determine whether a particular user is 
likely to encounter a known bug. Per example, where the 
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software is for- deigning programmable logic devices, it could 
be . the case that a particular bug only affects operation of 
the software with respect to a particular family of BLDs By 
studying previous use data associated with the software 'it 
i may be determine whether the user has ever worked with' that 
device family and. therefore, whether the bug should be fixed 
ra one embodiment, the software is simply not analyzed with * 
respect to such a bug. In another embodiment, the user L 
given the option of deciding whether the bug should be fixed 

Once all of the modules have been checked (step 328) 
it is detormined whether any modules have been placed on the 
upgrade list (step 330). where no modules have been 
designated for upgrade, the upgrade software routine ends and 
the user may proceed with norma! operation of the software. 
If. however, an upgrade has been repeated by the user for at 
least one module, the user's software is shut down (step 332, 
«ad new modules are downloaded from the vendor to the user's 
Platform (step 334) and written over the corresponding modules 
on the upgrade list (step 336, . A diagnostic ofthe IX 
configured software modules is then performed to ensurt proper 
operation (step 338, . Once the diagnostic indicates plc^ 
operation, the routine ends and normal operation of tL 
software may proceed. 

„. Mpmt t0 th8 nature <* the above-described procedure, 

the difficult task of ensuring that customers are using thT 
most recent version of a vendor's software is greatly 
facilitated. As will be understood, the upgrading of 
software especially ecm*lex design tools, is desirable for . 

^°\™,« r T pie - * is virtu — £ - 

Discover all of the bugs in a software program before 
distributing it to customers, rn fact, it is the use by a 
large customer base which produces all of the condition! 
needed to expose any hidden problems. Therefore, once such 
problems are exposed, portions of the software ateJl-* w . 
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However, as discussed above, registration of 
software by a customer base has historically been 
inconsistent. This has provided an obstacle to upgrading 
software packages in that the vendor's information about its 
customer base has been correlativaly inconsistent. Even where 
registration is accomplished, it is often difficult for a 
vendor to identify the appropriate individual in a customer's 
organization to effect the upgrade due to the fact that people 
frequently change their employment situations. 

The manner In which software upgrades have been 
traditionally effected has also been problematic. In addition 
to the difficulties associated with identifying customers and 
contacts , the distribution of the new code on some digital 
storage medium is both costly and time consuming. Moreover, 
once the new code is in the hands of the customer, there is no 
guarantee that it will be installed correctly on the 
customer's system. Xn fact, many of the problems that 
customers encounter in the use of software is a direct result 
of incorrect installation and/or configuring of the software. 

These problems are exacerbated by the fact that, especially 
during the period immediately following release of new 
software, several upgrades a year may be necessary. 

The software upgrade method described herein 
addresses each of these problems. Because the user is asked 
each time she boots up when an upgrade is available and/ or 
recommended, it is much more likely that each user will have 
the latest version of the software, no matter how many 
upgrades occur. Moreover, the necessity for keeping track of 
the appropriate contact' person at each customer is eliminated 
in that, because the upgrade is done directly with each user, 
there is no longer a role for such an individual in the 
transaction. The cost and delay which characterized previous 
distribution schemes is also no longer an issue. Shipping, 
production, and advertising costs are virtually eliminated, 
and the only delay is due to the customer's refusal to 
authorize an upgrade. Finally, because installation and 
configuration of the software is exclusively under the control 
of the vendor, the incidence of incorrect installations should 
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be dramatically reduced, in addition, if a vendor has 
accurate records regarding its customer base (a* would be the 
case, for example, where a vendor employs the registration 
process described above with reference to Fig. 2), it could 
independently track whether or noc specific customers are 
using the moat current version of their product by Keeping 
track of the customers who have requested an upgrade. Simply 
by being aware of the current version being used by its 
various customers, a vendor will be able to provide a greater 
level of customer service. 

Fig. 4a is a flowchart 400 illustrating a technique 
by which a diagnostic routine may be performed on software on 
a user's platform from a remote platform. When, during 
operation of software on a user's platform (step 402), either 
an error occurs, the user indicates that in her opinion an 
error has occurred, or the user wishes Co requests an 
enhancement to the software (step 404), the software 
determines whether access to the Internet is available (step 
.406) for the purpose of connecting to the vendor of the 
software. If Internet access is not available, a dialog box 
instructs the user to contact the vendor, providing, for 
example, the name, phone number, and e-mail address of an 
appropriate contact person (step 407) . rf , however, Internet 
access is available, a dialog box is generated which queries 
the user as to whether remote troubleshooting should begin 
(step 408). if the user responds affirmatively (step 410), a 
connection between the user's platform and the software vendor 
is established via the Internet (step 412) and, if an error is 
indicated (step 413), a critical bug table is downloaded from 
the vendor's platform to the user's (step 414). Otherwise, 
the routine proceeds directly to step 437. The critical bag 
table contains a list of toown bugs, each of which has an 
associated condition list which is a list of internal 
conditions of the software by which the associate* critical 
bug is characterized. These internal conditions represent tho 
state of internal variables in the software after the critical 
bug has occurred. 

A critical bug is selected from the table (step 416) 
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and a condition ie selected from the condition list associated 
with the selected critical bug (step 418). if the selected 
condition matches an internal condition of the user's software 
(step 420) and there are conditions in the list which have not 
been checXed (step 422), the next condition in the condition 
list is selected, if, the routine makes it through all of the 
conditions in the list, i.e., all of the conditions in the 
list match the internal conditions of the user's software, the 
associated critical bug is assumed to be the cause o£ the 
software error and is reported as suoh to the user via a 
dialog box (step 424) . However, as soon as the routine 
encounters a single condition in the condition list which does 
not match the internal state of the software, and where all of 
the critical bugs in the critical bug table have not been 
checked (step 426), the next bug in the table is selected for 
comparison of its condition list to the software. 

Once a known bug is reported to the user at step 
424 # the user is asked whether the software should be upgraded 
to correct the bug (step 428). In response to the user's 
authorization, the user's software is shut down (step 430) and 
software modules corresponding to the identified bug are 
downloaded from the vendor's platform and written over the 
corresponding; modules on the user's platform (step 432). A 
diagnostic ie then run to ensure that the software is 
correctly configured and operational (step 434) . If at step 
428 the user does not authorize the upgrade, she is instructed 
to contact the vendor as described above (step 407) . 

Where at step 426 all critical bugs have been 
checked ana no matches found, a dialog box is generated by 
which the user is informed that the error is likely due to an 
unknown bug (step 436) . Authorization is then requested to 
upload any necessary files from the user's platform for 
troubleshooting of the problem on the vendor's platform (step 
437) . if the user grants authorization to upload the 
requested files (step 438), a list of files and other 
necessary information regarding the user's system and the 
state of the software is compiled and presented to the user to 
obtain a second, informed authorization for the upload (step 
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440) . Where che user baa reviewed the list and given 
authorization, the information is uploaded to the vendor's 
platform (step 444), confirmation of which is transmitted back 
to the user (step 446) . With the user's files and the other 
information from the user's systems, the vendor may then 
recreate the conditions under which the failure occurred, 
thereby reproducing and, hopefully, correcting the problem 
If authorisation for the upload of information is not granted 
in either of steps 438 or 442, the user is Instructed to 
contact the vendor as described above (step 40?) . 

Pig. 4b is a flowchart 401 illustrating another 
technique by which a diagnostic routine may be performed 
remotely on software on a user's platform, steps 402 through 
436 are the same as described above with reference to Fig 4a 
However, if all critical bugs in the critical bug table have 
been checked, i.e., no matches have been found (step 426) a 
dialog box is generated by which the user Is informed that the 
error is likely due to an unknown bug (step 436) 
Authorisation is then requested to remotely run the software 
from the vendor's platform using files on the user's platform 
(step 437'). if authorisation is granted (step 439), the 
software is run fro» the vendor's platform (step 441). if 
not. the user is instructed to contact the vendor (step 407) 

The remote drive of this specific embodiment of the 
inventxon steps sequentially through the software command, of 
the user's software until an error condition is reached. that 

teChaiqUB attea * t8 Co «««*e the error condition 
originally encountered by the user without having to upload 
.11 of the user's files which, for a programmable logic 
design for example, can be rather large, zf, through this 
remote drive technique, a particular module of the user's 
software is identified as causing the problem (step 443) . the 
defective module is reported to the user (step 44*7 and ^ 
module may be upgraded as described above vich reference to 

ttTllT *\!T^ Pr ° bleW t8tep 4471 ' deceive 
fxle is reported to the user along with vendor contact 

information for additional support in solving the identified 
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problem (step 449) . If the remote drive can neither identify 
defective software modules nor defective user files, the user 
is Instructed to contact the vendor as described above (step 
407) . 

The advantages of the above-described embodiments of 
the invention are manifest. Prominent among these ic the feet 
that the time between the occurrence of an error in the 
operation of a software program and the diagnosis and 
correction of the error by the vendor is dramatically reduced. 

The user does not have to contact the vendor. Except for a 
few dialog boxes, the process is virtually automatic. Even in 
the case where the user's problem is the result of some 
unknown bug, tha present invention provides alternative levels 
of troubleshooting designed to solve the problem as quickly 
and efficiently as possible, in each case, the vendor gets an 
accurate "snapshot' of the user's system and data files so 
that the error is corxectly reproduced, thereby ensuring that 
the appropriate troubleshooting approach is taken. 

The importance of solving customer problems so 
guickly cannot be overstated. The programmable logic design 
market is exemplary in this regard. Any periods of time in 
the design of a programmable logic device during which the 
design process is not moving forward is extremely costly. One 
of the main focuses for many vendors in this area of 
technology is reducing the amount of time required to get a 
chip to market. The efficiency with which the present 
invention facilitates and supports the design process is a 
significant advancement toward this goal. 

Fig. 5 is a flowchart 500 which illustrates the 
manner in which a user of software may access help files which 
are resident on a remote platform maintained by the vendor of 
the software, when, during operation of the software, the 
user requests help (step 502), the software on the user's 
platform determines whether access to the Internet is 
available (step 504). i£ Internet access is not available 
the user's software generates a dialog box which provides 
information to the user regarding how to obtain technical 
support from the vendor (step 505) . if, however, Internet 
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access is available, a dialog box is generated which informs 
the user about online help Available from the vendor (step 
508) . it the user decides to use the online help (step 510) , 
a connection between the user's platform and the vendor is 
established via the Internet (step 512) . Otherwise, the user 
is provided with the technical support information at step: 
S0«. a menu of help topics is then downloaded from the 
vendor's platform and provided to the user (step 514). in 
response to the selection of a topic or topics by the user 
(step 516), nelp cn« 8 associated witn the selected topic (s) 
are downloaded to the user's platform (step 518) . if the user 
does not make a selection, i.e., cancels the request, the 
support information described above with reference to step 506 
is provided. 

The online technical support described above is 
another way in which the present invention facilitates optimal 
use of a software program. Because the help t±lw are located 
on the vendor-s platform, they can be updated as necessary to 
reflect the current state of the software sod to incorporate 
any additional information vhich may become apparent to the 
vendor over time. According to the invention, one way in 
which such information may be collected is through monitoring 
by the vendor of the help requests from its customer base L 
compiling statistics regarding the use of its help utility 
the vendor can determine which help files are most frequently 
requested. This information, in turn, may be ueeful in 
guiding the vendor's efforts to improve its product as well as 
in focusing technical aupport resources. 

The various aspects of the present invention all 

its customers to provide a more responsive level of service 
and technical support. There are a number of other advance, 
which may also be realised as a result of this paradigT^r 
staple, software vendors may tax. advantage of the frequent 
connections to customer platform, to provide information^ 
their customer base regarding new end related products for 
which the customer might have an interest. More specifically 
based on information gathered about specific customers over I' 
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period of tine, a vendor may be able to provide such 
information in a format and with content specifically tailored 
to the needs of each customer. Thus, the present invention is 
also useful for facilitating an adaptive ana forward-looking 
customer- vendor relationship . 

Fig. 6 illustrates an example of a computer system 
that may he used to execute the software of an embodiment of 
the invention. That is, system 601 is exenjplary of . for 
example, workstation 100 and/or server 110 of Fig. 1. 
Computer system 601 includes a display 603 r screen 60S, 
cabinet 607, keyboard 609. and mouse 611. Mouse 611 may have 
one or more buttons for interacting with a graphical user 
interface. Cabinet 607 houses a CD-ROM drive 613, system 
memory and a hard drive (see Pig. 7) which may be utilised to 
atore ana retrieve software programs incorporating caffgmter 
cede that implements the invention, data for use with the 
invention, and the like. Although the CD-ROM 615 is shown as 
an exemplary computer readable storage medium, other computer 
readable storage media including floppy disks, tape, flash 
memory, system memory, and hard drives may be utilized. 

Pig. 7 shows a system block diagram of computer 
system 601 used to execute the software of an embodiment of 
the invention. As in Fi CT . 6. computer system 601 includes 
monitor 603 and keyboard 609, and mouse 611. Computer system 
601 further includes subsystems such as a central processor 
701, system memory 703, fixed disk 705 (e.g., hard drive), 
removable disk 707 (e.g.. CD-ROM drive), display adapter 709, 
sound card 711, speakers 713, and network interface 715. 
Other computer systems suitable for use with the invention may 
include additional or fewer subsystems. For example, another 
computer system could include more than one processor 701 
(i.e., a multi-processor system), or a cache memory. 

*he system bus architecture of computer system 601 
is represented by arrows 717. However, these arrows are 
illustrative of any interconnection scheme serving to link the 
subsystems. For example, a local bus could be utilized to 
connect the central processor to the system memory and display 
adapter. Computer system 601 shown in Fig. 7 is but an 
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example of a computer system suitable fox use with the 
invention. Other computer architectures having different 
configurations of subsystems may also be utilized. 

While the invention has been particularly shown and 
described with reference to specific embodiments (hereof, it 
will be understood by those sJtilled in the are that changes in 
the form and details of the disclosed embodiments may be made 
without departing from the spirit or scope of the invention. 
Tor example, several of the examples in this specification 
were related with reference to software for designing 
programmable logic devices. However, it is clear chat the 
principles described herein may be applied to a wide variety 
of software programs. Therefore, the scope of the invention 
should be determined with reference to the appended claims. 
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WHAT IS CIAHBB jlfii 

1 . A method for upgrading first: software 
comprising: 

in response to operation of the first software on a 
first platform, establishing a connection between the first 
platform and a remote platform; and 

where first version data associated with the first 
software are different from second version data from the 
remote platform, overwriting a first portion of the first 
software with first updated code from the remote platform. 

2. The method of claim 1 wherein the first 
software comprises a plurality of software modules, and 
wherein the overwriting occurs for each of the plurality of 
software nodules for which the first and second version data 
are different. 



3. The method of claim 1 further comprising, where 
known error data from the remote platform correspond to the 
first software, overwriting a second portion of the first 
software with second updated code. 

4. The method of claim 3 further comprising 
downloading the known error data from the remote platform to 
the first platform. 

5. The method of claim 1 wherein establishing the 
connection comprises establishing an Internet connection. 

6. The method of claim 5 further comprising; 
determining whether access to the Internet ie available. 

7. The method of claim 1 further comprising 
obtaining authorisation from a user of the first software to 
establish the connection. 



method of claim 7 further comprising, where 
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authorization is not obtained, providing software support 
information to the user of the first software. 

9. The method of claim 1 further comprising 
shutting down operation of the first software before 
overwriting the first portion of the first software. 

10. The method of claim 1 further comprising, after 
overwriting the first portion of the first software, running a 
software diagnostic routine on the first software. 

11. The method of claim l further comprising 
downloading the first version data from the remote platform to 
the first platform. 

13. At least one computer readable medium 
containing program instruction, for upgrading first software, 
said at least one computer readable medium comprising, 

of t». m/TT* read0bl ° COd * £ ° r ' «Ws. to operation 
of the first software on a first platform, establishing a 
connection between the first platform and a remote platform; 

AaM .i //!!*r* r readable eode "he" first version data 

version f. ^ "* ^ B ° f ^ — ««ond 

Z£2 of 1, « ^ reB ° te Platf0m ' a first 

portion of the first software with first updated code from the 
remote platform. ne 

wav* an * " * A c ™vut*r data signal embodied in a carrier 
wave and representing sequence* of instructions which. wh« 
executed by at least one processor, cause said at least on" 
processor to upgrade first software by, 

first miaai* Mat><mae to of the first software on a 

first platform, establishing a connection between the first 
Platform and a remote platform, and 

M _ "h*™ first version data associated with the first 

^tlZlll ' fr0a <«m the 

*™ote platform, overwriting a first portion of the first 
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software with first updated code from the remote platform. 

14. A computer readable medium containing program 
instructions corresponding to first software, the first 
software having been upgraded according to a method 
comprising: 

in response to operation of the first software on a 
first platform* establishing a connection between the first 
platform and a remote platform; and 

where first version data associated with the first 
software are different from second version data from the 
remote platform, overwriting a first portion of the first 
software with first updated code from the remote platform, 

15. A method for troubleshooting first software 
comprising: 

in response to an error in operation of the first 
software on a first platform, establishing a connection 
between the first platform and a remote platform; and 

where the error corresponds to known error data from 
the remote platform, overwriting a portion of the first 
software with updated code. 

16. The method of claim 15 further comprising 
downloading the known error data from the remote platform to 
the first platform. 

17. The method of claim 15 wherein establishing the 
connection comprises establishing an Internet connection. 

18. The method of claim 17 further, comprising 
determining whether access to the internet is available. 

IS. The method of claim is further compriaing 
obtaining authorisation from e user of the first software to 
establish the connection. 



20. The method of claim 15 further comprising. 
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where authorisation ia not obtained, providing software 
support infomation to tha user of the first software. 

21. The method ot claim is further comprising * 
shutting down operation of the first software before 

overwriting the first portion of the first software. 

22. The method e f claim 15 further comprising, • 
after overwriting the first portion of the first software, 
running a software diagnostic routine on the first software. 

23. The method of claim 15 further comprising, 
where the error does not correspond to the known error data, 
uploading data files associated with the first software from 
the first platform to the remote platform via the connection; 
and 



reproducing the error on the remote platform usino 
the data files. 

24. The method of claim 23 further comprising 
obtaining authorisation from a user of the eirst software for 
uploading the data files. 

25. The method of claim 24 further comprising 
where authorisation is not obtained, providing software 
support information to the user of the first software. 

26. The method of claim 23 further comprising 
before uploading the data files, compiling information from 
the first platform regarding the data files. 

27. The method of claim 15 further comprising 
where the error does not correspond to the known error data 
operating the first software on the first platform fro* the 
remote platform via the connection, thereby reproducing the 
error on the first platform. 

29. The method of claim 27 further comprising 
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obtaining authorization from a user of the first software for 
operating the first software from the remote platform. 

29* The method of claim 28 further comprising, 
where authorization is not obtained, providing software 
support information to the user of the first software. 

30. At least one computer readable medium 
containing program instructions for troubleshooting f ixst 
software, said at least one computer readable medium 
comprising: 

computer readable code for, in rmspona^ to an error 
in operation of the first software on a first platform, 
establishing a connection between the first platform and a 
remote platform; and 

computer readable code for, where the error 
corresponds to known error data from the remote platform, 
overwriting a portion of the first software with updated code. 

31. A computer data signal embodied in a carrier 
wave and representing sequences of instructions which, when 
executed by at least one processor, cause said at least one 
processor to troubleshoot first software byx 

in xesponso to an error in operation of the first 
software on a first platform, establishing a connection 
between the first platform and a remote platform; and 

where the error corresponds to known error data from 
the remote platform, overwriting a portion of the first 
software with updated code. 

32. A computer readable medium containing program 
instructions corresponding to first software, the first 
software having been troubleshot according to a method 
comprising: 

in response to an error in operation of the first 
software on a first platform, establishing a connection 
between the first platform and a remote platform,- and 

where the error corresponds to known error data from 
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the remote platform, overwriting a portion of the first 
software with updated code. 
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METHOD FOR PROVIDING 
REMOTE SOFTWARE TECHNICAL SUPPORT 

ABSTRACT OP THE DISCLOSURE 
A method for upgrading software is described. 
According to the invention, in response co operation of the 
software en e first platform, a connection is established 
between the first platform and a remote platform, where first 
version data associated with the software are different from 
second varaion data from the remote platform, a portion of the 
software is overwritten with first updated code from the 
remote platform. 
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